observability 向き合い
主に Kubernetes へのデプロイを前提とする
ラベルによるリソースの認識がうまく存在する世界
こういうのものがない世界では設定の疎結合性とかはない
やりたい
設定の疎結合性
o11y に関連する設定はアプリケーションのデプロイメントに関与するのであって，監視ミドルウェアで長いアプリケーションの列を管理したくない
既存のアプリケーションの利用
全部 OpenTelemetry でやってくださいというわけにはいかない
そもそもログが stdout に吐かれてくれないと困るが
種類別
メトリック
アプリケーションのレイヤだと OpenMetrics (aka. Prometheus exporter のフォーマット)か OpenTelemetry になると思われる
OpenMetrics の場合 pull させるため監視ミドルウェアがエンドポイントを知る必要があるが Prometheus の kubernetes_sd_configや Prometheus Operator の Monitor 系リソースがこれを可能にする
OpenTelemetry の場合 push なのでエンドポイントの問題はない
どうやって push 先のエンドポイントを得るか？という問題はあるがクラスタ内にデフォルトサービスがあればそこまで問題にはならない
tosuke.icon としては pull 型の OpenMetrics のほうが curl 一発で確認できる容易さという点で好みだけれどどちらでもいい
特にトレースを扱っている場合は otel の計装の準備ができているからそのまま otel でやってしまったほうが楽なような気もする
共存は OpenTelemetry Collector 使えばまあできるでしょう
三択くらいある
1. prometheus receiver を使って OpenMetrics を OpenTelemetry に寄せる
2. prometheus exporter を使って OpenTelemetry を OpenMetrics に寄せる
3. OpenTelemetry を使うときは Prometheus に push する
Prometheus の OTLP 対応を使って直接 OR otelcol w/ prometheus remote write exporter を使って間接
Prometheus がシングルインスタンス運用ならどれを選んでもうまく動く
複数インスタンスの場合分散方式によって考える余地が生まれる
Pull ベース分散
複数インスタンスが1つの exporter にそれぞれリクエストを飛ばす方式
2 を採用するべき
が Thanos を使っているなら Thanos Receiver を使って Push ベース分散を併用する道もある
Pull ベースな分散は exporter 単位でしか分割ができないので利用可能なら Push ベースのほうがよい気もする
Push ベース分散をしている場合割とどうにでもなる
なぜなら Prometheus のベースが Pull である時点でこの手の方式は Pull を受け入れる口を持っているから
前述した otelcol の prometheus receiver はその選択肢の1つ
attribute / label へのマッチングベースの書き換え / メトリックの削除といった設定をアプリケーションごとにいい感じに設定する方法はほぼない
ほぼないが，あんまりそういうことをしたい機会がないので必要になったら otelcol をサイドカーにすればいいんじゃないかなあ
監視のためのルールの記述はどうしようもなくて困る
ログ
stdout / stderr に吐く一択だと思う
OpenTelemetry にもあるが，送信プロトコルとしてあるのは便利だがアプリケーションで使うのは微妙だと思う
開発中に見たいから
集める手段は色々あります
fluentd (or fluent-bit)
よくしらない……
promtail
otelcol w/ filelogreceiver + receivercreator + k8s-observer でできそう
ちゃんと取るのはまあまあ面倒
ログ落とさないようにする https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/e867aa84edb2dbe0570b57681ba62bdbf92e1d37/examples/fault-tolerant-logs-collection/otel-col-config.yaml
システムログは journald から取ったりする
promtail には journald source があるし，otelcol にも journaldreceiver がある
ログはメトリックと違って各アプリケーションが適当に吐いているので横断的な情報を取るためにパースをかける必要があるが……
少なくともタイムスタンプと severity くらいは欲しいが，一般にはアプリケーションごとに異なる
JSON だったら……みたいな分岐をかけ，その下で色々やることはできる気がする
テンプレート芸といった感じに
トレース
OpenTelemetry 一択だと思う
それ以外のやつが広く使われるなら otelcol の receiver にする，そこまで使われていないならサイドカーで対応
あんまりどう運用されるべきなのかわからん，自分の中のユースケースが不足している
一番自由度の低い構造なのでだいたいの項目が横断的関心事として処理できるように見える
計装される側は環境変数である程度動作を変えられるようにしておき，外からは otelcol をサイドカーで注入しても DaemonSet とかで起動して環境変数だけ投入するとかでも同じ感じで使えるようにしておくとよさそう